Ensuring network connection security between a wrapped app and a remote server

ABSTRACT

A network connection between an app on a mobile device and a remote server is either enabled or denied based on whether a security wrapped app can verify that the connection is with a known and trusted server. The wrapped app uses a socket interception layer injected into the app code along with a trust store, also part of the wrapped app to determine whether a network connection attempted by the app should be allowed. The layer buffers relevant function calls from the app by intercepting them before they reach the device operating system. If the layer determines that a network connection is attempted, then it snoops the negotiation phase data stream to discern when the server sends a certificate to the app. It obtains this certificate and compares it to data in the trust store and makes a determination of whether the server is known and trusted.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority under U.S.C. §119(e) to pending U.S.Provisional Application No. 61/662,555 filed Jun. 21, 2012, entitled“PROTECTING NETWORK CONNECTIONS AND DATA TRAFFIC TO AND FROM ANAPPLICATION ON A DEVICE”. This application is also aContinuation-in-Part which claims priority under 35 U.S.C. §120 topending U.S. patent application Ser. No. 13/875,151 filed May 1, 2013,entitled “CREATING A VIRTUAL PRIVATE NETWORK (VPN) FOR A SINGLE APP ONAN INTERNET-ENABLED DEVICE OR SYSTEM”, which is a Continuation-in-Partof U.S. patent application Ser. No. 13/025,994, filed Feb. 11, 2011,entitled “SECURING AND MANAGING APPS ON A DEVICE”. All applications arehereby incorporated by reference in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to software, network communications, andmobile devices. More specifically, it relates to security of apps andassociated data running on mobile devices and connecting to remoteservers.

2. Description of the Related Art

Application security is becoming increasingly important, especiallyapplications on mobile devices, commonly referred to as apps. Often,these apps have to communicate with a remote server, such aswork-related or employer-owned apps on a user's personal device. Manyapps are now using Transport Layer Security (TLS), (also referred to asthe Secure Socket Layer or SSL) for establishing network connectionswhich may be used for communication with external components. Otherprotocols and standards are also being used for communication between anapp on a device and a remote server. Note that the means forcommunication, whether TLS or another protocol, is at the app level,rather than at the device level. However, while TLS is a relativelysecure means for communicating, there are certain ways to subvert orundermine an TLS connection. For example, a hacker or unauthorized partymay be able to convince a certificate authority to sign off on a falsecertificate which appears authentic. Thus, a hostile party may be ableto obtain a false certificate and pretend to be from a well-known andtrusted company. This false certificate can then be used to subvert aTLS connection with an app on a mobile device, thereby threatening theapp, data, the device operating system, and potentially the devicenetwork. It would be desirable to have greater protection for apps andassociated data on mobile devices; that is, provide better protectivemeasures at the app layer rather than at the device (physical, operatingsystem, or network layers). Such protective measures should execute withTLS connections and should also be used with non-TLS clients.

SUMMARY OF THE INVENTION

In one aspect of the present invention, method of enabling a networkconnection between an app on a mobile device and a remote server isdescribed. An app on a mobile device is wrapped, thereby making itsecure on the device. By wrapping the app, a sockets interception layeris injected into the app. This layer resides on top of the app-dedicatedIP stack within the wrapped app. Also injected into the app is a truststore, also referred to as a certificate store. The method begins withthe sockets interception layer intercepting function calls, such asreads and writes, from the app that would normally go to the operatingsystem. Thus, such function calls from the app do not go to theoperating system of the mobile device.

The sockets interception layer determines whether an app is attemptingto make a network connection by examining function calls and bufferingthose that are considered relevant. In one embodiment, a function callis considered relevant if it is to or from a socket that was opened foruse as an Internet connection and if the socket is a stream-basedsocket. As noted, the sockets interception layer observes or examinesthe data stream between the app and the remote server. It buffers allfunction calls that are considered relevant, that is, have to do withcommunicating with a remote server. The layer determines whether the appis attempting to make a connection with a remote server. If it is not,then the normal operations of the app continue. If it is, the socketsinterception layer discerns the certificate sent from the remote server,since at this stage it knows that the app is attempting to connect to aserver. In one embodiment, it can do this by snooping the data streamduring the negotiation phase (handshaking phase), looking for certaintypes of messages, and knowing when to expect a certificate from theserver. The sockets interception layer of the app obtains thecertificate and transmits it to or compares it to the contents of thetrust store. For example, it may check to see if the certificate is froma known and trusted certificate authority. By doing this, the wrappedapp itself can determine whether it can trust the server, that is, isthe server a known entity that the app (and the device) can trust. If itis, then the connection is allowed to be made with the server andpost-negotiation data (i.e., normal app-related data) can then betransmitted to and from the app.

BRIEF DESCRIPTION OF THE DRAWINGS

References are made to the accompanying drawings, which form a part ofthe description and in which are shown, by way of illustration, specificembodiments of the present invention:

FIG. 1A is a block diagram showing an overview of the app controlprocess of the present invention;

FIG. 1B is a block diagram showing an alternative embodiment of an appcontrol process of the present invention;

FIG. 2 is a block diagram showing components of an app security programin accordance with one embodiment of the present invention;

FIG. 3 is a flow diagram showing a process of making an app securebefore downloading it on to a device in accordance with one embodimentof the present invention;

FIG. 4 is a flow diagram of a method performed in policy manager inaccordance with one embodiment;

FIG. 5 is a flow diagram showing a process of a security-wrapped appexecuting on a handset or mobile device in accordance with oneembodiment;

FIG. 6 is a system architecture diagram of the app security controlsystem in accordance with one embodiment;

FIG. 7 is a block diagram showing components and modules in a mobiledevice needed for implementing a per-app VPN in accordance with oneembodiment;

FIG. 8 is a flow diagram of a process of implementing an app VPN inaccordance with one embodiment of the present invention;

FIG. 9 is a block diagram showing components relevant to ensuring TLSsecurity between an app and a remote server;

FIG. 10 is a flow diagram of a process of determining whether a TLSconnection can be trusted and is from a known entity at the time it isbeing established between a mobile device and a remote server inaccordance with one embodiment; and

FIGS. 11A and 11B are block diagrams of a computing system suitable forimplementing various embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Example embodiments of an application security process and system aredescribed. These examples and embodiments are provided solely to addcontext and aid in the understanding of the invention. Thus, it will beapparent to one skilled in the art that the present invention may bepracticed without some or all of the specific details described herein.In other instances, well-known concepts have not been described indetail in order to avoid unnecessarily obscuring the present invention.Other applications and examples are possible, such that the followingexamples, illustrations, and contexts should not be taken as definitiveor limiting either in scope or setting. Although these embodiments aredescribed in sufficient detail to enable one skilled in the art topractice the invention, these examples, illustrations, and contexts arenot limiting, and other embodiments may be used and changes may be madewithout departing from the spirit and scope of the invention.

Methods and system for preventing device software applications frominfecting or otherwise damaging a device, in particular, a mobiledevice, are described in the various figures. These types ofapplications, used often on a variety of mobile devices, such as smartphones, tablet computers, gaming devices, and portable computing devicesare commonly referred to as “apps.” These apps may also be downloaded onto non-mobile devices, such as TVs, computers, automobiles, and otheremerging smart device categories. Methods and systems described are notintended to be limited to operation on mobile devices. These deviceprograms or apps have proliferated and are now very prevalent.Currently, apps are typically written in either Java or C. The methodsand systems described herein may be applied to apps written in either orto apps written in other languages for different platforms. Most apps,if not all, have to communicate with the mobile device's operatingsystem to get a specific service that the app needs in order to performits intended function and this service is usually only available fromthe operating system. A common example of such a service used is GPS toget the location of the device which the app may need. However, becauseof this exposure, apps are a vulnerability for the device and pose asecurity and privacy risk for the user. Companies want to be ableenforce a centralized policy to control and secure access to its dataand software. This is also true for end users (i.e., individuals, homeusers, and the like). It enables enterprise IT departments to maintaingovernance of corporate data. The methods described below provide acentralized way to control security with respect to apps that aredownloaded onto mobile devices, where the devices are either anemployee's personal phone or an employer's phone, so that those apps donot pose a security threat. Various embodiments of the invention mayalso be used by parents and individuals (i.e., in home or non-workenvironments) to ensure that their personal mobile devices are safe frommalware and may also be used to apply controls, such as on usage.Embodiments of the app control software of the present invention mayalso be used for mobile device data protection and back-up and forapplication-level telemetry.

FIG. 1A is a block diagram showing an overview of the app controlprocess of the present invention. It is a generic description of oneprocess without being tied to a specific configuration or environment.An app 102 is provided by app provider 100 which can be any type ofentity (individual, software developer, employer, etc.). It is generallyunprotected and the only security surrounding it is provided by theoperating system. The only shield and checking done on how it executeson the device once loaded is provided by the operating system.

The present invention enables additional security of the apps that isnot provided by the device's operating system. A security applicationprogram 104 is applied to app 102. Or the app 102 is input to program104, which may be supplied by a third-party app security provider. Inone embodiment, security application program 104 has a policy managerand a policy wrapper which may be in different locations. They aredescribed in greater detail in FIG. 2. Once security program 104 hasbeen applied to app 102, the app is wrapped with a security layer sothat the device is protected. It is shown as secured app 106. In oneembodiment, secured app 106 is then downloaded onto a mobile device 108,such as a smart phone or tablet computer, where it executes securelywithout risking damage to device 108. Another benefit is that securedapp 106 may also be managed by the company or other entity that isproviding the app to the user, such as an employer providing the app toan employee. For example, if the user leaves the company, the companymay automatically delete the app and any related data from the device.In another example, a parent may be able to limit the apps used byanother person (e.g., a child) or to limit the amount of time, e.g., 10minutes a day or limit which Web sites may be accessed by an app. Or, aparent is concerned that an app is leaking a child's location to unknownthird parties. There may be numerous other examples. As noted, FIG. 1Ais intended to show the general process of securing an app anddownloading it onto a device. Note that in this embodiment, app 102 isnot made secure from causing harm to the device after it is downloadedonto the device, but before. In another embodiment, the app is securedafter it is downloaded onto the device, but before it can interact withthe operating system.

FIG. 1B is a block diagram showing an alternative embodiment. Anunsecured app 110 (also supplied by an app provider) is downloaded ontomobile device 112. In this embodiment, however, there may be a speciallydesigned app on device 112 that blocks the actual installation ofunsecured app 110. The special app (not shown) redirects unsecured app110 to an app security program 114. The unsecured app 110 is wrapped ina security policy, the resulting app shown as secured app 116. It isthen downloaded and allowed to be installed on device 112 by the specialapp. In this manner, an individual or home user, for example, who wantsto protect her phone from security threats posed by apps, can have appsmade secure (wrapped) by a third-party service or by her mobile phonecarrier, to mention only two examples, before they are downloaded on toher phone. It should be noted that this security wrapping can be done toan app regardless of where the user downloads the app from. It may alsobe noted that in FIGS. 1A and 1B, the network and connections betweenthe components and software are shown generically. The transmissions areprimarily over the Internet (not shown) but may also be within a privatenetwork or both.

FIG. 2 is a block diagram showing components of an app security programin accordance with one embodiment of the present invention. In oneembodiment, the security program has two major components, a policymanager and a policy wrapper. A policy manager 202 accepts input from anadministrator or other individual who is responsible for settingsecurity for the mobile device. The person may be referred to as thegovernor since he is governing the security of the one or more mobiledevices. The security policy may be set using various user interfacescreens. There are numerous examples of policies, including geo-fencing(e.g., the app can only be used in a building) and others. The serviceprovider or the entity providing the app security program may alsoprovide default policy and security settings which may be useful forhome users. Examples of policy settings are described below. Policyinput 204 is inputted into policy manager 202. Policy manager 202 takesthe input/settings from the governor and creates policies or meta-data206. The format or form of meta-data 206 can vary. They essentiallyreflect the policy settings from the governor.

Metadata (policies) 206 may be used as input to a policy wrapper 208. Inone embodiment, this component of the program takes the policies anduses them to secure an app 210 by wrapping it. Wrapper 208 receives anapp 210 from a handheld device 212. In one embodiment, wrapper 208receives a copy of an app 210 instead of the original app 214 that wasdownloaded onto phone 212 (see FIG. 1B above). Here the handheld device212 user attempts to download an unsecured app 216 from an app provider218. In the scenario in described in FIG. 1A, it may operate on the appitself instead of a copy. This may be the case where a market place orapp store offers customers a secured version of the app along with anunsecured version (or only offer the secured version). A secured version220 (security-wrapped version) is returned from policy wrapper 208 todevice 212.

Metadata 206 may also be used to update a local policy file (an existingpolicy that is already on the device). A local policy file is used toupdate policy parameters residing on device 212. For example, in thecase of “geofencing” (i.e., restricting use of an app to an certainphysical areas) it is likely that the GPS locations controlled by thegovernor will change over time. When such a change occurs, the newpolicies can be applied in two different ways. One is to generate a newpolicy and apply it to the original app (i.e., wrap the app with the newpolicy). Another way is to allow dynamic configuration based on a localpolicy data file with the “variable” part of the policy encrypted/signedinside it. For example, an IT person may want the ability to override aconfiguration on a device directly through an IT app residing on thedevice for diagnostic purposes.

In one embodiment policies have two components: a fixed part and avariable part. The fixed part is the content described in the policyfile (e.g., “protect the GPS at certain times of day”). The variablepart typically is provided by the governor through a console (e.g. “whatare the times when the GPS should be protected?”). The variable part canchange without applying a new policy.

Policy designers can choose to forego the variable component of thepolicy and basically “embed” all data or content statically in thepolicy file. In this case, the console does not have any way tocustomize the policy.

If the policy designer chooses to include some variable component in thepolicy, when changes are made to the variable data (on the console), anew data file could be sent to the device to reflect the latest changes.Such a file would be encrypted/signed (to prevent a malicious appcircumventing the policy), downloaded to the device, and used by the appsecurity code on the device to apply the new data to the appropriatepolicy.

Such changes and updates may be done by local policy update component222 at runtime. This component creates updated policy parameters ondevice 212. Thereafter, wrapped app 220 will use the updated policyparameters.

In one embodiment, policy manager 202 and policy wrapper 208 arecomponents in the same app security program and may operate on the samecomputer. In other embodiments, the manager and wrapper components maybe on separate computers. For example, the policy manager 202 may be ona server at one site and the policy wrapper 208 may be on a computer atanother site and may be managed by a different entity or the sameentity. Collectively the manager and wrapper form the app securityprogram which, in one embodiment, is operated by a security serviceprovider. It may also be provided by an enterprise, such as a company,employer, business partner, and the like, or by a mobile phone carrier.

FIG. 3 is a flow diagram showing a process of making an app securebefore downloading it on to a device in accordance with one embodimentof the present invention. At step 302 a copy or clone of the app that isto be secured is made on the device. In one embodiment, this may be doneon the mobile device itself or may be done off the device, for example,on components on the Internet, in the cloud, on an enterprise's serveror on a carrier server. The user may be an individual, an employee of acompany or other entity. As is known in the field, an app may beobtained in a number of ways, most typically from an app store or an appmarket, or directly from the app developer or provider or in anysuitable manner. By making a copy, the original app is preserved givingthe user an option to use either the secured or unsecured version andalso protects the user's ability to use the app if something goes wrongwith the app control process. Note that in one embodiment, the app isnot yet downloaded on to the phone. In one embodiment, the methodsdescribed below are performed on separate computing devices. In anotherembodiment, the process may be performed on a mobile device, but the appis only executed on the device after the process is complete and the apphas been made secure.

At step 304 the app is decapsulated. Most, if not all, apps have digitalsignatures signed by the author/developer. At step 304, as part of thedecapsulation, the digital signature is removed from the app. This maybe done using techniques known in the art. Decrypting the app may alsobe performed at this step. These and other steps provide the core objectcode of the app which may now be operated on by the app control program.The nature and specifics of this operation may depend on the mobiledevice's operating system.

There are several examples of operating systems for smart phones such asiOS (for the iPhone), Android (used on handsets from variousmanufacturers), Windows Mobile 7, Web O/S, Palm, and others. At step306, the core object code app may be either disassembled or decompiledto obtain the executable object code. For example, it can be either“native code” (CPU instructions) or bytecode (virtual machineinstructions, such as Java or .Net). In one embodiment, this may be moreof a modification process if the device runs iOS where the disassemblyis closer to a process of locating and substituting certain links andterms. However, in general, the disassembly process to obtain the objectcode of an app after it has been decapsulated may be done usingtechniques known in the art, such as using disassemblers.

At step 308 the app object code is augmented with object code from theapp security program. For example, this object code may include classfiles which are replaced with class files from the security program. Theobject code generally provides an interface to the mobile deviceoperating system. The app control security program object code isderived, in part, from the policy/meta-data described above. In the caseof iOS, the operation is different in that a ‘locate and substitute’process occurs rather than an object code replacement. This takes intoconsideration an interrupt approach that iOS's uses. Generally, the appsecurity program goes through the assembly language code. The specificitems located are Software Interrupts (SWIs) within the object code andwhich are replaced with a branch to an app control security programlayer which may then determine what further actions to take, such asmaking the request, enhancing the results, and others, as describedbelow.

At step 310, after substitution of the object code (or substitutions ofSWIs) has been made, the app security program prepares the securitywrapped app for execution on the mobile device. The object codesubstituted into the app by the security program generally provides abridge or connection between the app and the mobile device operatingsystem. The security program class files may be described as wrappingaround the operating system class files. The app security program classfiles are generated based on the policies created earlier (by input fromthe governor). The app is essentially re-wired for execution on thehandset. It is re-wired to use the app security program layer inaddition to the security provided by the mobile device operating systemlayer. That is, the secured app may still be subject to the securityprovisions of the operating system. In one embodiment, certain cosmeticchanges may also be made to the app, such as changing the icon for theapp to reflect that it is secured. By doing this, the user can be surethat when the app icon appears on the handset screen that the securedversion of the app will be executed. The app has now essentially beenre-factored or re-programmed by the security program.

At step 312 the app is signed with a new key, for example, with the keyof the service provider or the key of the enterprise providing thesecured app. The re-factored, secured version of the app is returned tothe handset device. In another embodiment, the app is wrapped with thesecurity layer on the phone. At step 314, in one embodiment, theoriginal, unsecured copy of the app is deleted from the handset device.This may be done by the secured version of the app once it is downloadedonto the handset. In other embodiments, this is not done and bothversions remain on the mobile device. At this stage the process iscomplete.

FIG. 4 is a flow diagram of a method performed in policy manager 202 inaccordance with one embodiment. At step 402 the governor or othersecurity policy individual is enabled to define, generate, and createsecurity policies. This may be a network administrator for an enterprisedeciding a vast array of mobile device security policies for hundreds ofemployees using dozens of enterprise apps (specifically for work) thatmay be downloaded on hundreds or thousands of mobile devices. On theother end of the spectrum, it may be a parent who is setting securitypolicy for three or four apps downloaded by her child on a new mobiledevice. Other examples include preventing or squashing a gaming appusing GPS, preventing an app from using a microphone on the device torecord or eavesdrop on a conversation, among many others. In eithercase, the governor may take into consideration the category of the app,the type and nature of app, the author, the age-appropriateness, andnumerous other factors. For example, has the same author written anyother apps that may have been classified as malware or posed a securitythreat to the device. It may determine whether there are other apps bythe same author. It is at this stage that the governor decides whichrules to apply for each app. In one embodiment, this is done off-line bythe governor. That is, it may be done using user interfaces on a homecomputer or on an enterprise network computer used by an administratorwhere security templates provided by the security program serviceprovider (essentially default templates) may be used or very specificrules may be set using the templates.

At step 404 the security data input at step 402 is used by the appcontrol security program to create the actual policies. At step 406 theapp control security program object code is generated based on the inputfrom the governor regarding security policies created at step 404. Thegovernor or service provider may also update existing security policiesif needed. As described above, the object code may be used to enhancecertain original object code obtained from the disassembled app. Theenhancement code is inserted to adjust security and privacy settings foran app in order to protect the enterprise and end user. The originalapp's behavior is altered which allows the governor to control how theapp behaves. For example, if an app stores sensitive account informationin the clear (i.e., un-encrypted), the behavior could be changed so thatall information the app creates is stored in encrypted form and whichcan only be accessed by that app given that the key to the stored,persistent data would be unique to the app. In many instances theenhancement code can improve the apps performance since the code isoptimized for a particular use scenario.

FIG. 5 is a flow diagram showing a process of a security-wrapped appexecuting on a handset or mobile device in accordance with oneembodiment. At step 502 the behavior of the app when the app executes orimmediately before it executes on the device is altered or modified. Forexample, behavior modification may include authentication during appinitialization; e.g. smart/CAC card, or password challenge. Some apps,as originally designed, may not require a password for security,however, a secured version of an app which has been modified may requirethat the user enter a password. At step 504 the secured app executes onthe mobile device by the user activating it (e.g., tapping on the iconif the device has a touch screen). Upon execution of the app, in oneembodiment, control can take one of four options. As is known in theart, when an app executes, it makes calls or requests to the deviceoperating system in order to carry out its functions. In many casesthese calls may be harmless or pose no significant security threat tothe phone or device. If this is the case, the call may be allowed topass to the operating system as shown in step 506. Here the call is madeto the device operating system and the app executes in a normal manner.

If the security layer or wrapper around the app detects that the app ismaking a request that may pose a security threat to the device, the appsecurity layer may enhance or modify the request before it is passed tothe operating system or other software or hardware component in thephone. This is shown at step 508. In one embodiment, the governordetermines which calls are permissible by examining the one or morepolicies. For example, the governor may determine that all data shouldbe saved in encrypted form. In another example, the governor may decidethat only a select group of trusted apps should have data on a soldier'sGPS coordinate. In one embodiment, there is no runtime logic todetermine what is safe, a potential threat, or an actual threat; it isessentially pre-declared by the governor in the policy created at step404 above. In another embodiment, there may be some runtime logic. Forexample, an app may be trying to send out expensive SMS text messages.The app control program may determine this and block the app fromsending more than a certain number of text messages, for example, it maylimit it to transmission of one message. The enhancement may be addingsomething new, such as a password requirement. In another example, ifthe call is to save data on the mobile device memory, the secured appmay actually back up the data to a storage area in the cloud or on theInternet (i.e., off the device). In another example, the data related tothe call may be encrypted.

At step 510 the secured app may determine that the call is an actualthreat and should be dealt with in a more severe manner than at step508. For example, it may have decided that based on the policy for anapp, that if a camera on the device is accessed while in a securebuilding (e.g., the Pentagon), the app should immediately be terminated.Merely enhancing the request may not be sufficient in this case. At step510, the request may not be allowed to proceed to the operating systemor any other component of the device. However, in one embodiment, aresponse is returned to the app, but that response is intentionally notaccurate or correct. It is essentially an obfuscated response. Forexample, it may be a GPS coordinate that is not the actual physicalcoordinate of the device (e.g., the device is in California, but the GPScoordinate that is returned to the app is a coordinate in Nebraska).This may be desirable when apps are used by children. Other examples maybe returning bad or garbled data results if an app that should only runwithin a restrictive environment (e.g., a secure office area) isdetermined to be running outside that environment (e.g., at home). Inthis example, the app may be partially crippled so that the app can onlyaccess unclassified data and wherein classified information isnullified. In another example, when a user is attempting to paste orcopy sensitive data from a classified app to a non-classified app, theapp control program may change the copy of the data that is being pastedto garbage or essentially make it meaningless. After either steps 506,508, or 510 have completed, the security-wrapped app continues executionon the mobile device at step 514.

At step 512 the security layer around the app has determined that thecall being made by the app or that the app execution behavior in generalposes too high a security threat level to the mobile device. In thisextreme case, the security layer decides to terminate execution of theapp and/or delete the app. For example, the app may be using too manyresources on the phone, such as bandwidth, or is making too manyhigh-risk calls to the operating system thereby over-exposing the mobiledevice. In this case, the app can simply be deleted from the phone orthe app may be terminated. The user may not be able to re-execute it orre-install it. For example, an employee may not install that app againon the company phone because it was exposing sensitive company data. Orit may be determined that an app is secretly collecting data on thephone or installing malware.

FIG. 6 is a system architecture diagram of the app security controlsystem in accordance with one embodiment. A trigger manager component602 handles two events, one for generating a new policy 604 and anotherfor updating policy parameters 606. Such events can be triggered byvarious systems. For example, a console administrator or governor mightapply a new policy to all devices (a manual operation). Or a networkmonitoring application, after detecting suspicious traffic originatingfrom a device (or app), could push a new policy that would prevent auser/device/app from accessing network resources (an example of anautomated operation). The various systems or entities that have theauthority to change/update polices, do so through the trigger manager602.

New policy output 604 is input to a policy definition file 608 which maybe generated at runtime and may include various types of code andextensions, for example, specific to the app control service provider,or to the app/user/device the policy applies to. Policy definition file608 is input to a policy compiler 610 which has two outputs. One outputis a wrapper definition file 612. This file is input to an app wrappercomponent 614. App wrapper component 614 is responsible for generatingsecure app by injecting custom binary code (native or bytecode) into anapp, downloaded directly, for example, from an app store. Or the appcould be an app the user downloaded on to his device, and then uploadedto an “AppControl” server.

App wrapper component 614 may have three inputs: apps from one or moreapp stores 616, certificate key management data from identity managementcomponent 618, and hardened components 620. Key management data is usedto tie the identities of the user, device, and the app, and ensure thatany operation subject to policy control can be tied to a specificuser/device/app. This also ensures that a wrapped application can onlybe run on a specific device to prevent a malicious app fromcircumventing policies and hardened components 620 (for example “Devicesecurity framework”). The output from app wrapper 614 is a wrapped app622 which is downloaded or installed onto mobile device 624 via thedevice's controller 626. Device controller 626 responsibilities include:download app from the app wrapper; ensure that app running on thedevices are appropriately wrapped apps (e.g., app wrapped for user1should not be installed/run on device for user2); report list/version ofinstalled applications to allow the management console to controlpolicies for each device/user/application; and download policyparameters when appropriate. Wrapped app 622 resides on device 624coupled with policy parameters 628.

Returning now to policy compiler 610, the other output is a runtimepolicy definition file 630. This file is input to a runtime policycompiler 632 which also accepts as input policy parameters 606(specified by the management console, or other subsystems). Output fromcompiler 632 is a device runtime policy file 634. This file 634 isdownloaded onto device 624 as shown as policy parameters 628, and isused to customize the policies applied to wrapped app 622.

Described below are various use cases and capabilities of the appcontrol security program of the present invention. One use case involvesthe separation of work life and personal life on a mobile phone. Thereare apps for the user's personal use and apps that the user's employer(or a business partner of the employer) may have provided and the appsoperate on the same phone, which is often the user's personal phone. Thegovernor who determines security of the apps that need to be secured onthe user's phone may block copy/paste operations between apps (such ase-mail apps). The governor may set policies for the work-related appsthat perform selective wipes of apps and associated files. Userlocation-based policies may also control where certain apps may execute.Examples of levels of protection because of malware are denying accessto contacts, denying transmission of SMS without consent, and the like.

Another example of a use case is app control. Using the presentinvention, white and black listing of apps may be implemented, as wellas full deletion of apps according to the policies set by a governor. Anapp may be ‘sandboxed’ to protect the other apps, software, and hardwareof the device. Other capabilities may include identity-based control ofapps or services and highly granular control over app behavior. Trojanidentification is another use case that can be implemented with the appsecurity program. For example, each app and content may be encrypted toprevent rogue apps from gaining access to and stealing confidential dataon the phone. The security program may also be able to identifyanomalous system call behavior of an app to identify malicious Trojanapps that act outside of their published intent.

Another use case is back-up and recovery of app data in which ITsecurity administrators and governors have data revision control and canimplement app and device content migration through back-up and restoreoperations. In another use case is network traffic monitoring. The appon the mobile device may be brought under the visibility of existingenterprise IDS/IPS/Web filtering infrastructure to allow for inspectionand control of app communications. The app security program can alsointegrate with third-party DNS services, such as Symantec's DNS serviceto identify malware. All app communications may be encrypted, includingcommunications at the mobile phone service provider. Other use casesinclude session continuity, consumer privacy (e.g., GPS obfuscation,implementing safe DNSs), and intercepting payment/transaction messagesfrom the mobile device (i.e., operating in the middle of mobile commercestreams).

In one embodiment, the app security service is offered by a third-partyservice provider, for example, to make apps used by end-users orindividuals (i.e., users not associated with an employer or enterprise).For example, a parent may want to obfuscate the GPS of a child's phonebecause the parent does not want a social network site, such asFacebook, to know where the child is, essentially disabling GPS. Inanother embodiment, an app store, operated by a wireless phone carrier(e.g., Verizon, AT&T) may offer a secured app for an extra charge orpremium. A customer of the carrier can download the secured app from themarketplace or online store instead of the unsecured version by payingan extra amount. In another embodiment, an enterprise may have its ownapp store for its employees, partners, and the like, where users canonly download secured versions of the apps (which may be referred to as“hard” apps). These apps may have many of the security featuresdescribed above as defined by a governor (security administrator) at theenterprise, such as blocking copying and pasting e-mail or corporatedata, killing an app from the user's phone if the user leaves thecompany, and so on. A mobile phone carrier's DNS can typically accessany site, but the app security program can block a mobile device browserso that it can access only a safe DNS (e.g., Symantec's DNS) from whereonly safe Web sites may be accessed. In another embodiment, the appsecurity program provider can work with the mobile device manufacturerto incorporate the app security program or functionality into thehardware and software operations of the device. In this embodiment,described below, a user can download an unsecured app and make issecured on the phone or device itself before executing and does not haveto access a third-party service to have the app secured or ensure thatthe app is secured before being downloaded onto the device.

As can be seen from various embodiments described above, the security ofthe mobile device extends beyond the device itself and is applieddirectly to the apps that are downloaded onto the device. Companies andother entities are able to take advantage of apps more freely withouthaving to worry about the security risks, such as data leakage ormalware infection of the company's enterprise IT system. Companies canmaintain governance of its corporate data.

In another aspect of the present invention, a VPN is created andutilized by individual apps on a device. That is, an app has a VPNtunnel to communicate with, for example, a corporate VPN gateway. ThisVPN tunnel is used only between the single app on the device and the VPNgateway. In one embodiment, each security wrapped app has its own IPstack or, more generally, VPN stack. Methods and systems for creating aVPN tunnel for a specific wrapped app on a device are described in FIGS.7 and 8.

As noted above, conventionally, a VPN tunnel is built (on theclient/device side) on top of the system UDP or TCP modules, which inturn communicate with the VPN gateway. In the described embodiment, thedevice may be a smartphone, tablet, or other mobile device. In otherembodiments, the device may be a PC or a laptop. It may also be awearable device, such as a watch, goggles, or other nomadicInternet-enabled computing device. In yet other embodiments, the devicemay be any Internet-enabled appliance or system. Examples include carsthat have Internet access, household appliances (refrigerators, washers,etc.), or HVAC, home heating/AC systems, or security systems. As noted,the described embodiment uses mobile devices where users download apps.However, the present invention may also be used in other embodiments andcontexts.

Generally, there is software on the device, such as a smartphone,tablet, PC, or other Internet-enabled device, that allows it to make aVPN connection to a gateway device. However, the described embodimentprovides a more compartmentalized way of creating and utilizing a VPNtunnel on the device that is more secure. In one embodiment, eachwrapped app has its own VPN tunnel. In another embodiment, some or allapps in a federation of apps on a device have the option of sharing oneVPN tunnel. A secure form of IPC may be used to communicate between theprocesses in the case of a “federated” application. As described in moredetail below, IPSec packets may be built for each wrapped app (eachwrapped app operating in its own sandbox, that is, outside the deviceoperating system). The IP packets are transmitted via a proxy or virtualdata link layer (part of the app VPN stack) to a native UDP module inthe operating system. From there it is transmitted to a VPN gateway. Asnoted above, the device may also be a PC. For example, a PC running awrapped version of Microsoft Outlook may have its own VPN tunnel fromthe PC to the gateway

In order to establish a VPN tunnel, an initial step is to create onlypacket types that a typical operating system makes available toapplications. For example, to connect to an IP-based VPN, an applicationcan use TCP or UDP packets. In the described embodiment, the app IPstack uses UDP packets. Generally, it should not use “raw” IP packets(without a specific Layer 4 protocol), because such packets aretypically reserved by operating systems so that only privilegedapplications may send or receive them. A per-app VPN, as described invarious embodiments of the present invention, is not required to be aprivileged process on the device. NAT traversal of IPsec packets isenabled using UDP protocol (as described in RFC 3947 and RFC 3984),rather than raw IP packets.

In order for an app to send data through a VPN tunnel to a gateway, theapp must be able to build IP packets which are then encapsulated usingVPN software on the device. The IP packets are built using an IP stack.This software typically resides in the operating system of the device.Therefore, in order for a per-app VPN to operate, in one embodiment, theapp makes use of an IP or VPN stack that is used to build a tunnel thatis only used between the single application and the gateway. That is, inone embodiment, it is not used by other apps. This stack may also bereferred to as a per-app IP stack, in the app sandbox. The goal being togenerally replicate operating system functionality in the sandbox.

In order for any IP stack to access an outside network, it uses softwarereferred to as data link interface (also known as Layer 2, per theTCP/IP and OSI networking models). In one embodiment of the presentinvention, and as shown in FIG. 7, this data link interface isimplemented as a proxy (or virtual) data link interface to an underlyingoperating system's (native) IP stack. In one embodiment, given that onlyUDP packets are sent and received, this proxy data link interfacesupports sending and receiving UDP traffic via the native operatingsystem's IP/VPN stack and the per-app IP/VPN stack. An IPsec moduledecrypts the inbound traffic coming from the virtual data-link layer,and encrypts the outbound traffic from the per-app IP stack.

IPsec is typically implemented as a “bump in the [IP] stack”, and isintegrated into an operating system's IP stack. In one embodiment, IPsecis implemented in the per-app IP stack instead. As noted, a proxy orvirtual data link interface for IPsec is defined in the per-app IPstack. The IPsec encapsulates traffic (IP packets) built through theper-app IP stack and routes the traffic via the proxy data linkinterface, in one embodiment, to a UDP module in the native operatingsystem space.

FIG. 7 is a block diagram showing components and modules in a mobiledevice needed for implementing a per-app VPN in accordance with oneembodiment. Shown are the two relevant memory spaces on a mobile device702: a sandbox area 704 containing components of a wrapped app, systemcomponents, and an IP/VPN stack, and a device operating system space706. Also shown, external to mobile device 702, is a VPN gatewaycomponent 708. As noted above, embodiments of the present inventioninvolve creating and implementing an IP stack for a security wrapped appin sandbox area 704.

An IP stack 710 has some of the conventional layers of a TCP/IP stack,such as network layer and transport layer. Above IP stack 710 is an HTTPproxy or sockets layer 712. Two components in app IP stack 710 are IPsec714 and proxy data link layer 716. Virtual data link layer 716 functionsas an IP interface to between virtual IPsec 714 and native UDP module722. The combination of virtual IPsec 714, virtual data link layer 716,and IP stack 710 may also be referred to as a “per-app VPN” stack. Theprimary goal of the per-app VPN stack of the present invention is toreplicate operations and functionality that take place in nativeoperating system 706. Components for a single app and any systemcomponents reside in sandbox area 704. However, for illustration, onlyone app component 718 and one system component 720 are shown.

Native operating system 706 contains several components, including asystem-level or native IP stack (not shown). One of the modules inoperating system space 706 needed for the present invention is a UDPmodule 722. As noted, IPsec packets are transmitted from mobile device702 to VPN gateway 708 using UDP. In other embodiments, TCP may be used.Data packets for the security wrapped app are also received from VPNgateway device 708 at UDP module 722 and relayed to proxy data linklayer 716.

FIG. 8 is a flow diagram of a process of implementing an app VPN inaccordance with one embodiment of the present invention. Asecurity-wrapped app in sandbox 704 executes in a normal manner and inthe process makes calls to the device operating system, some of whichrequire communication over a VPN. This occurs at step 802. In oneembodiment, those calls are re-directed to app IP stack 710 at step 804.In one embodiment, The interfaces that are exposed to the application(and app and system components, boxes 718 and 720) through HTTP proxylayer box 712 mirror the corresponding interfaces provided by operatingsystem 706.

At step 806 the app IP stack builds IPsec packets in a conventionalmanner. This would normally be done by the system/native IP stack as aresult of an app or system component in the sandbox making a call to theoperating system. IP packets are then encapsulated using IPsec in theapp VPN stack. At step 808 a proxy data link layer, also part of the appVPN stack, transmits packets to a UDP module in the system/native IPstack. In other embodiments, where an SSL VPN is implemented, thepackets may be transmitted to a TCP module. As noted, the proxy(virtual) data link layer functions as an interface between the app IPstack and the system native stack, specifically the UDP module. TheIPsec module can be described as a virtual IPsec interface. Thisinterface together with the virtual data link interface functions to getIP packets down through the app VPN stack and out through the native UDPmodule to the VPN gateway.

It may be noted that this is possible by virtue of using network addresstranslation (NAT). As is known in the art, this technique allows anentity to allocate “private” IP addresses which are mapped to public IPaddresses. The private IP addresses are never seen by the public.Traditional NAT approaches are able to rewrite an IP packet and thensend it to a different, private address.

As noted above, by configuring a particular application with its own VPNtunnel, one could configure the app security wrapping server to restrictaccess to network resources so that the app can only access the specificresources it needs. If HTTP proxy 712 is listening on a TCP portprovided by operating system 706, other applications could potentiallyconnect to that TCP port. In one embodiment, HTTP proxy layer 712implements techniques to prevent other applications on the device fromaccessing the HTTP proxy. In one embodiment, the system determines if aconnection to the HTTP proxy layer 712 came from the current process(i.e., the wrapped, host app), for example by looking through all thefile descriptors in the current process and checking with the kernel todetermine if any of file descriptors made the connection to HTTP proxylayer 712. If the authenticity of a group or federation of apps can bevalidated and establish communication between those apps, in oneembodiment, the federated apps can share a single VPN tunnel. Althoughthis would lower the number of concurrent VPN tunnels needed for adevice, it may detract from some of the advantages described above, suchas configuring a server to restrict access to network resources suchthat the app can only access the specific resources it needs.

As such, in one embodiment, only the specific security wrapped app canconnect to the VPN tunnel that is created by that app's VPN stack. Thisprevents another malicious app or any other malware on the device fromstating that the HTTP proxy for another app is also the proxy for themalicious app, thereby preventing the malicious app from using thewrapped app's VPN. In another embodiment, a VPN tunnel created by asecurity wrapped app may be shared by other wrapped apps in the samefederation or group as the app that created the VPN.

In another embodiment, a device user may need a VPN to gain any type ofaccess or connectivity at all (e.g., if the user is working abroad in acountry with restrictive Internet access), the user can access adevice-level VPN to gain initial full-internet access, and then use aper-app VPN to gain corporate access.

Another advantage of tying a single application to a VPN tunnel is theability to restrict, at the VPN gateway, the network resources that theapplication has access to, by using a different “configuration profile”(i.e., VPN group) per application.

In another aspect of the present invention, the service provideroffering app security services implements mechanisms through appwrapping to ensure that a TLS connection or other type of networkconnection between a wrapped app and a remote server (e.g., a companyweb server or a VPN gateway) is indeed secure and being made by a knownentity before the connection is established and used to transmit actualapp data (e.g., sensitive employer data, user financial data, sessiontokens). As is known in the art, prior to transmission of actual dataused by the app, a negotiating phase occurs (over the same channel ofcommunication), whereby the TLS protocol allows the app and the remoteserver to agree on security parameters. This negotiation phase isrelevant to various embodiments of the present invention.

In one embodiment, the app uses TLS for establishing networkcommunications and connections. In general, the overall process involvescomponents in the layer that wraps the app, wherein the components arefor intercepting network communications to and from the app to determinewhether the app is attempting to make a remote connection and, if it is,snooping or inspecting the TLS handshake traffic, and deriving ordiscovering an certificate, and determining whether the certificate istrustworthy and from a known entity. If the certificate, in oneembodiment an X.509 certificate, cannot be trusted, the TLS connectionis denied by the app wrapping layer, as described in more detail below.In addition, if an app is not using TLS at all, its connection attemptscan be denied before application data is transmitted or received.

FIG. 9 is a block diagram showing components relevant to ensuring TLSsecurity between an app and a remote server. As described above, an appis wrapped on a mobile device using methods described in variousembodiments shown in FIGS. 1 to 6. A VPN tunnel may be establishedbetween a specific app (or a federation of apps) and a VPN gatewayserver (one type of remote server) as described in FIGS. 7 and 8. In oneembodiment, a TLS connection can use the VPN tunnel described above orit may not.

Some of the components in FIG. 9 are also described in FIG. 7. Shown arethe two memory spaces on a mobile device 902. One is a sandbox area 904containing wrapped app components 918, system components 920, and an IPstack 710, all necessary for app execution but not directly relevant toembodiments of the present invention. The other memory space 906 storesa device operating system which includes all the conventional modulesand components of a mobile device operating system, including a socketslayer which normally receives traffic to and from apps executing inmemory space or sandbox 704. Also shown, external to mobile device 902,is a remote server 908. As noted above, embodiments of the presentinvention involve ensuring that a TLS or other connection betweenwrapped app 918 and server 908 is in fact secure before it is used fortransmitting actual app data.

On top of IP stack 910 (specifically for the wrapped app) there is asockets interception layer 912. This layer 912 intercepts certainfunction calls, including reads, writes, and information about the typeand destination of each opened socket, from the app. Reads and writesfrom the wrapped app would normally go to a sockets layer in operatingsystem 906 of the mobile device but instead are re-directed to thesockets interception layer 912. However, in various embodiments of thepresent invention, these calls go to sockets interception layer 912 ofthe wrapped app IP stack 910 which has the conventional layers of aTCP/IP stack, such as network layer and transport layer. Anothercomponent in memory area (sandbox) 904 is a trust store 922. Thiscomponent, as well as sockets interception layer 912, are inserted orinjected into the app when the app is security wrapped. Trust store 922contains trusted certificates from certificate authorities known to thesecurity service provider. Its use is described below in FIG. 10. Asnoted, components for a single wrapped app and any system componentsreside in sandbox area 904. However, for illustration, only one wrappedapp component 918 and one system component 920 are shown.

Native operating system 906 contains several components, including asockets layer (not shown) which normally receives calls from an app.However, in various embodiments of the present invention, once an app iswrapped, reads, writes, and other data traffic from the app do not go tothe operating system sockets layer. They are intercepted by socketsinterception layer 912.

FIG. 10 is a flow diagram of a process of determining whether a TLSconnection can be trusted and is from a known entity at the time it isbeing established between a mobile device and a remote server inaccordance with one embodiment. The process begins at any time duringapp execution. An app can attempt to open as many TLS connections as itneeds at any time during its execution, including when it is initiallyinvoked. The connection is with a remote server, such as acorporate/employer web server (e.g., to exchange business data with theapp), a VPN gateway, or any other type of server that the app needs toconnect to. Of course, an app can execute and not attempt to open a TLSconnection or any other type of connection with a remote server. Theprocess described in FIG. 10 is performed regardless of whether the appattempts to open a TLS connection. That is, components of the wrappedapp do not know a priori that the wrapped app will open a connection.

At step 1002, the sockets interception layer on top of the IP stack forthe wrapped app receives or intercepts reads and writes to and from thewrapped app and other function calls. This traffic to and from thewrapped app (not the device in general) is re-directed and buffered bythe sockets interception layer when the app is invoked or opened by auser. The sockets interception layer buffers all relevant reads andwrites in sandbox 904. Relevance may be determined by whether a sockethas been opened for communication with the Internet and if it is astream-based socket. In one embodiment, determining why a socket hasbeen opened may be done by checking if it is within a certain allowedrange of hosts on the Internet. In one embodiment, non-stream basedsockets, such as UDP, can be immediately closed. In another embodiment,UDP sockets' data transfer can be examined to ensure that they areproperly secured with DTLS, a derivation of SSL which has the samesecurity services but uses UDP for its transport protocol.

Once a socket has been opened and its type has been determined, a uniqueidentifier (often called a file descriptor) can be used to correlatefuture reads and writes against a particular network (socket)connection. These reads and writes are subsequently buffered by theinterception layer, until the connection is determined to be secure andallowed to remain open, or the connection is determined to not besecure, and the connection is dropped. This is done at step 1004. Thatis, the sockets interception layer associates buffered read/write datawith network server connections by examining the messages sent by theTLS protocol. In particular, the certificate sent by the remote serverto the application (which would normally be verified by the application)is subjected to additional verification against the trust store,previously injected into the app.

At step 1006 the interception layer determines whether the app isattempting to make a server connection. If it is determined that the appis attempting to make a connection, such as a TLS connection, to anetwork server, control goes to step 1008. If no network connectionattempt is detected from examining the buffered data, the app continueswith normal operations at step 1010.

At step 1008 socket interception layer observes the data stream betweenthe app and the remote server. That is, it looks at the traffic which itnow knows is between the wrapped app and a remote server and is for thepurpose of establishing an TLS connection or another type of networkconnection. The wrapped app (not the device) and the remote server arein the TLS negotiation phase. At this stage the interception layer issnooping on the SSL handshake or negotiation phase data between the appand the remote server. In one embodiment, the purpose of this snoopingis to discern and eventually piece together what is referred to in thefield as an X.509 certificate, the certificate sent from the remoteserver in order to establish the connection.

Conventionally, an app running on a mobile device does not attempt tovalidate, in any manner, an X.509 certificate but allows a trustedframework on the device to do it on its behalf. This is because an appnormally does not attempt to make a TLS connection on its own. Itgenerally would have the device operating system perform this function.However, even the device operating system would not try to discern ordiscover an X.509 certificate from the remote server. The socketinterception layer examines the data traffic from the negotiationphase/handshake and from this traffic is able to identify thecertificate sent by the remote server. In particular, the interceptionlayer observes the TLS protocol handshake until it sees a ‘ServerHello’message. The socket interception layer then expects that the TLSprotocol will then send a ‘Server Certificate’ message containing theX.509 certificate.

In another embodiment, the interception layer may not receive or need aServer Certificate message if one was previously sent. If the layer haskept a session ID from a prior connection and if the security serviceprovider or app knows what this session ID should be, the ID can be usedfor rapid re-handshaking or session resumption, primarily because theconnection is being made without the need for re-sending the X.509certificate.

If the certificate cannot be discovered or discerned from snooping theTLS handshake traffic, the TLS connection between the wrapped app andthe remote server is not allowed. At step 1012 the interception layertransmits the remote server certificate to the wrapped app trust store(or certificate store) containing one or more certificates fromcertificate authorities that the service provider trusts. At step 1014,the certificate is compared to each of the trust store certificates tosee if there is a match between the issuer of the TLS certificate andany of the CA's in the trust store. In this manner, it is determinedwhether the TLS certificate from the remote server can be trusted. If itcan, control goes to step 1018. If not, the connection is denied at step1016 and an appropriate message is sent to the user and others, such anIT or network administrator at the user's company. If the certificate istrusted, a TLS connection is established between the wrapped app and theremote server and app operations continue normally.

The data is inspected to make sure that it meets certain criteria beforeit is allowed on a network and received by the app. In this respect, thepresent invention may be characterized as implementing a firewall for awrapped app, rather than for more conventional entities such as adevice, network, or operating system. As described above, the “per-appfirewall” of the present invention either accepts or rejects connectionsto the wrapped app itself. For example, the service provider inspects aTLS handshake to ensure that it matches certain criteria so that the appconnects to a known entity and not a hostile or unauthorized party.

As described in FIG. 10, the reads, writes, and other functions calls,and data traffic are intercepted, buffered, and inspected in real time,that is, while the app is running on the device. Thus, any TLSconnections attempted by the wrapped app are examined for security andtrustworthiness (i.e., the connection is being made with a known entity)while the user is using the app and without any noticeable difference inapp execution, performance, or behavior. Each TLS connection that ismade is inspected in real time. In other embodiments, criteria otherthan examining a certificate chain may be used for determining securityof the connection, such as examining a DNS name, an IP address, or theprotocol being used.

In one embodiment, the DNS traffic is intercepted and examined (andpossibly changed) to ensure that the connection is secure. In thismanner, DNS traffic may be protected. For example, a DNS entry may behard-coded into an app to prevent a “man-in-the-middle” attack againstthe DNS infrastructure, or DNS replies may be checked to ensure thatthey fall into a particular IP address range. This and the otherprotective measures described above are being done at the app level orlayer, not at the device (physical), operating system, or networklayers. The embodiments described may also be used with a non-SSLclient. In another embodiment, a DNS “whitelist” may be implemented,thereby having a DNS geo-fencing effect. An app may use built-in DNSinstead of device-wide DNS, so all app DNS queries go to a known,trusted (and intended) enterprise. In one embodiment, UDP communicationsfrom an app would be disabled to prevent data leakage, except forcommunications to the service provider's DNS.

FIGS. 11A and 11B illustrate a computing system 1100 suitable forimplementing embodiments of the present invention. FIG. 11A shows onepossible physical form of the computing system. Of course, the computingsystem may have many physical forms including an integrated circuit, aprinted circuit board, a small handheld device (such as a mobiletelephone, handset or PDA), a personal computer or a super computer.Computing system 1100 includes a monitor 1102, a display 1104, a housing1106, a disk drive 1108, a keyboard 1110 and a mouse 1112. Disk 1114 isa computer-readable medium used to transfer data to and from computersystem 1100.

FIG. 11B is an example of a block diagram for computing system 1100.Attached to system bus 1120 are a wide variety of subsystems.Processor(s) 1122 (also referred to as central processing units, orCPUs) are coupled to storage devices including memory 1124. Memory 1124includes random access memory (RAM) and read-only memory (ROM). As iswell known in the art, ROM acts to transfer data and instructionsuni-directionally to the CPU and RAM is used typically to transfer dataand instructions in a bi-directional manner. Both of these types ofmemories may include any suitable of the computer-readable mediadescribed below. A fixed disk 1126 is also coupled bi-directionally toCPU 1122; it provides additional data storage capacity and may alsoinclude any of the computer-readable media described below. Fixed disk1126 may be used to store programs, data and the like and is typically asecondary storage medium (such as a hard disk) that is slower thanprimary storage. It will be appreciated that the information retainedwithin fixed disk 1126, may, in appropriate cases, be incorporated instandard fashion as virtual memory in memory 1124. Removable disk 1114may take the form of any of the computer-readable media described below.

CPU 1122 is also coupled to a variety of input/output devices such asdisplay 1104, keyboard 1110, mouse 1112 and speakers 1130. In general,an input/output device may be any of: video displays, track balls, mice,keyboards, microphones, touch-sensitive displays, transducer cardreaders, magnetic or paper tape readers, tablets, styluses, voice orhandwriting recognizers, biometrics readers, or other computers. CPU1122 optionally may be coupled to another computer or telecommunicationsnetwork using network interface 1140. With such a network interface, itis contemplated that the CPU might receive information from the network,or might output information to the network in the course of performingthe above-described method steps. Furthermore, method embodiments of thepresent invention may execute solely upon CPU 1122 or may execute over anetwork such as the Internet in conjunction with a remote CPU thatshares a portion of the processing.

Although illustrative embodiments and applications of this invention areshown and described herein, many variations and modifications arepossible which remain within the concept, scope, and spirit of theinvention, and these variations would become clear to those of ordinaryskill in the art after perusal of this application. Accordingly, theembodiments described are to be considered as illustrative and notrestrictive, and the invention is not to be limited to the details givenherein, but may be modified within the scope and equivalents of theappended claims.

We claim:
 1. A method of enabling a network connection between an app ona mobile device and a remote server, the method comprising: duringexecution of an app on the device, attempting to open the networkconnection with the remote server; intercepting relevant function callsto and from a wrapped app, said intercepting done by a socketsinterception layer on top of an IP stack specifically for the wrappedapp, wherein said relevant function calls are re-directed to the socketsinterception layer and selected based on socket characteristics;correlating said relevant function calls with a particular networkconnection; discerning a certificate by observing data stream between anapp and the remote server; comparing the certificate with a trust storein the wrapped app; determining whether the certificate can be trusted;allowing the connection if the certificate is authenticated and trusted,the connection between the wrapped app and the remote server.
 2. Amethod of enabling a network connection between an app on a mobiledevice and a remote server, the method comprising: intercepting functioncalls between an app and a remote server; examining a function call todetermine if the call is over a network connection; determining whetherthe app is attempting to make a server connection; observing a datastream between the app and the remote server; obtaining a certificatesent by the remote server; determining whether the certificate istrusted by the app; and allowing the connection with the server.